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I.  ABSTRACT 


Achieving  "Tech  Transfer",  i.e.  "an  invention  usefully  adopted,"  is  difficult, 
particularly  within  the  Defense  Enterprise.  The  Defense  acquisition  system  is 
designed  to  transition  technology  through  a  long  serial  process  ill  suited  for 
Information  Technology  (IT).  However,  there  is  a  successful  commercial 
practice  for  transitioning  IT  called  "Product  Line  Architecture"  (PLA).  PLA 
optimizes  a  specified  open  standard  technical  framework  around  specific, 
measurable,  enterprise  business  objectives  and  streamlined  process.  There  are 
no  legal  or  technical  barriers  that  prevent  the  Defense  Enterprise  from  adapting 
PLA  to  leverage  the  IT  marketplace  for  transition  of  information  centric 
capabilities.  However,  several  fundamental  paradigm  shifts  in  policies  and 
perceptions  are  required,  namely: 

•  Specify  open  system  approaches  in  context  with  measurable  and  testable 
business  objectives,  as  part  of  procurement  requirements  i.e.  Defense 
Enterprise  PLA. 

•  Virtualize  inheritable  security  controls  into  open  standard  IT  infrastructure. 

•  Base  procurement  award  and  performance  incentives  on  demonstrated 
Validation  and  Verification  (V&V)  against  value-based  metrics,  including  for 
reuse  of  existing  components  and  infrastructure. 

•  Apply  expert  systems  technologies  -  per  Computer  Assisted  Design  (CAD), 
TurboTax,  and  workflow  automation  -  to  automate  the  Enterprise 
Information  System  (EIS)  design  and  compliance  process. 

•  Establish  a  persistent,  distributed,  "PlugTest"  virtual  environment  based  on 
Defense  Enterprise  PLA  to  implement  and  nurture  eco-system  per  all  the 
above. 

•  Use  the  PlugTest  environment  as  a  channel  to  catalyze  a  COTS  marketplace 
around  Defense  Enterprise  IT  requirements  writ  large. 
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IV.  INTRODUCTION:  SURVIVAL  OF  THE  FITTEST 


The  Industrial  Age  is  over  and  the  Information  Age  is  underway.  Many  old 
enterprises  have  not  survived  the  transition.  Today's  thriving  enterprises  do  so  by 
adapting  to  the  new  environment.  Non-state  terror  organizations  are  among  those 
that  have  adapted  well.  (United  Nations  Office  on  Drugs  and  Crime,  2012) 

The  new  environment  is  virtual,  distributed,  information-centric,  and  evolving 
dynamically.  From  an  information  systems  engineering  perspective,  the  gene  pool 
for  enterprise  evolution  is  the  Information  Technology  (IT)  marketplace. 
Metaphorically  speaking.  Open  Enterprise  Information  Systems  (OEIS)  can  serve  as 
the  cauldrons  for  stirring  the  primal  evolutionary  soup.  The  World  Wide  Web,  after 
all,  is  the  mother  of  all  OEIS!  Following  this  argument,  successful  system  evolution 
is  equivalent  to  "Technology  Transition."  Achieving  information-centric  tech 
transition  requires  understanding  and  executing  some  fundamental  departures 
from  industrial  age  system  development  paradigms.  For  example: 

•  Develop  enterprise,  or  in-line,  rather  than  point  solutions 

•  Build  open  systems  rather  than  closed  systems 

•  Harvest  and  recompose  successful  off-the-shelf  components  to  create 
new  capability. 


According  to  many  watchdog  reports  and  Congressional  mandates,  the  Defense 
Enterprise,  unlike  non-state  terror  organizations,  has  fallen  far  behind  at  evolving 
enterprise  information-centric  capability. 
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V.  WHAT  IS  SUCCESSFUL  TECHNOLOGY  TRANSITION? 


A,  TRANSITION  VS.  TRANSFER 

“Invention”  and  “innovation”  are  similar,  related  terms.  “Invention”  is  often  defined  as 
ereation  of  a  new  artifact,  and  “innovation”  as  useful  application  of  the  invention.  In 
other  words,  an  innovation  is  an  invention  that  has  been  adopted  in  a  way  that  changes 
prior  behavior. 

“Technology  Transfer”,  and  “Technology  Transition”  are,  likewise,  closely  related  terms. 
Transition  of  an  invention  is  equivalent  to  adoption  of  the  invention  by  a  community  of 
practice.  An  invention  that  becomes  an  innovation  has,  thus,  been  transitioned.  Transfer 
of  technology  typically  means  that  Intellectual  Property  (IP)  moves  from  the  technology 
developer  to  the  technology  applier.  This  transfer  may  be  formal  or  informal,  deliberate 
or  accidental,  voluntary  or  co-opted,  and  legal  or  illegal.  An  academic  or  government 
laboratory  might  allow  a  commercial  firm,  and/or  another  government  or  academic  lab, 
etc.,  to  use  its  invention  for  agreed  purposes.  Alternatively,  the  IP  might  be  released 
freely  into  the  public  domain,  or  be  involuntarily  reverse-engineered  by  technology 
pirates.  In  the  Defense  Enterprise,  transition  often  is  the  unintended  consequence  of 
COTS  IT  procurement,  even  though  virtually  no  transfer  occurs.  Exploitation  of  this 
opportunity  can  be  one  of  the  most  effective  approaches  for  meaningful  tech  transition. 
Regardless,  per  the  following  examples,  tech  transfer  is  an  often  useful,  but  certainly  not 
sufficient  condition  for  tech  transition. 

Eor  example,  government-funded  research  at  Rand  Corporation  led  to  the  invention  of 
packet  switching  technologies  in  the  early  1960’s.  The  IP  transferred  to  the  DoD’s 
Advanced  Research  Projects  Agency  (ARP A).  It  also  transferred  to  what  eventually 
became  the  Open  Systems  Interconnections  (OSI)  committee  of  the  International 
Standards  Organization  (ISO). 

The  OSI  committee  represented  a  huge  international  government  and  industry 
collaborative,  including  the  US  DoD.  The  OSI  committee’s  goal  was  to  transition  packet 
switching  technology  via  an  invention  called  “virtual  circuits”.  Their  approach  was  to 
gain  consensus  on  a  comprehensive  suite  of  standards  that  could  then  be  widely 
implemented.  In  fact,  in  1988  the  US  Department  of  Commerce  mandated  that  all  US 
government  computers  must  use  OSI  standards.  However,  implementation  of  OSI 
standards  turned  out  to  be  expensive  and  difficult.  Virtual  circuit  technology  never 
transitioned.  By  contrast,  the  ARPA-net  project  implemented  packet  switching 
technology  with  two  inventions  called  “Transmission  Control  Protocol”  (TCP)  and 
“Internet  Protocol”  (IP).  TCP/IP  was  cheap  and  easy  to  use,  so  people  adapted  it  for  any 
number  of  useful  purposes.  Standardization  occurred  after  early  adoption.  Therefore,  the 
Department  of  Commerce  mandate  to  use  OSI  standards  became  moot.  (Russell,  2013) 
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Similarly,  government-funded  research  led  to  the  discovery  of  satellite  navigation 
technology.  That  raw  technology  was  transferred  to  the  DoD  laboratories  that 
developed  the  Global  Positioning  System  (GPS).  The  DoD  transferred  access  to  the 
GPS  “selective  availability”  (previously  restricted  precise  data)  to  the  general  public  in 
2000. 

The  GPS  system  transitioned  satellite  navigation  technology  by  publishing  message  and 
data  formats  that  made  it  freely  and  easily  available  to  the  public.  Myriad  innovative 
products  and  services  consumed  the  GPS  navigational  data  and  turned  it  into 
extraordinarily,  convenient,  useful  and  lucrative  utilities 

Standards  for  the  Internet,  search  engines,  GPS  and  other  related  technologies  have 
evolved,  and  continue  to  evolve,  following  the  initial  adoption  of  demonstrated 
capabilities.  In  these  cases,  commercial  industry’s  innovative  technology  adoption,  and 
follow  on  standards  evolution,  has  exponentially  enhanced  the  government’s  ability  to 
harvest  the  potential  value  of  the  technology  that  the  tax  dollars  paid  to  invent. 

B,  HOW  TO  CROSS  THE  VALLEY  AND  THE  TROUGH 

The  difficulty  of  transitioning  a  promising  new  invention  into  a  useful  and  sustained 
utility  is  well  documented.  In  fact,  this  transition  is  so  difficult  that  literature  often  refers 
to  the  issue  as  “The  Valley  of  Death.”  The  consulting  company,  Gartner  Inc.,  has 
invented  a  similar  concept  to  describe  the  difficulty  of  transitioning  IT.  The  Gamer  calls 
its  approach  the  “Hype  Curve.”  Inevitably,  according  to  Gartner,  the  novelty  of  some 
newly  invented  IT  generates  excitement.  The  hype  increases  with  speculation  over  its 
potential  applications.  The  hype  dies  down  in  light  of  failure  to  immediately  live  up  to 
expectations.  Gartner  calls  the  long  difficult  period  between  the  peak  of  the  hype  and 
the  slow  climb  toward  useful  adoption  (in  those  cases  where  adoption  indeed  occurs)  the 
“Trough  of  Disillusionment.”  (See  figure:  1) 

Arguably  Clayton  Christensen’s  famous  book  “The  Innovator’s  Dilemma”  offers  useful 
insight  for  crossing  both  the  Trough  of  Disillusionment  and  the  Valley  of  Death. 
Christensen  describes  the  problem  in  context  with  “dismptive  technology.”  A  dismptive 
technology  is  one  whose  adoption  fundamentally  changes  community  behavior. 
(Christensen,  2003)  Inventors  love  it  when  their  inventions  become  dismptive.  On  the 
other  hand,  those  vested  in  the  status  quo  fear  dismptive  inventions  that  threaten  their 
comfortable  business  models.  For  example.  Defense  budgetary  processes  typically  cite 
maintenance  of  status  quo  capabilities  as  justification  for  continued  investment. 
Traditional  Defense  contractors  are  comfortable  with  that  status  quo.  Hence  deliberate 
adoption  of  dismptive  technologies  within  the  Defense  investment  is  problematic. 

Christensen’s  best  practices  for  catalyzing  dismptive  innovation  include  the  following: 

Target  potential  early  adopters  at  the  low  end  of  the  market  who  are 
underserved  by,  and  not  vested  in,  the  status  quo. 
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Provide  a  solution  that  is  cheaper  and/or  more  convenient  than  the  status 
quo. 

Implement  the  would-be  innovation  via  familiar  methods  that  are 
comfortable  to  the  implementers  on  one  hand,  and  won't  raise  defenses  of 
the  old  guard  on  the  other. 

The  Internet,  GPS,  and  web  services  are  disruptive  technologies  that  became  broadly  and 
usefully  adopted  as  the  fabric  of  the  World  Wide  Web  (WWW).  The  likes  of  Amazon, 
iTunes,  TurboTax,  Travelocity,  eBay,  etc.,  have  leveraged  Christensen’s  tenants,  within 
the  framework  of  WWW,  to  disrupt  the  brick-and-mortar  retail  industry. 
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Figure  1:  Gartner's  Hype  Curve.  The  Trough  of  Disillusionment  is  analogous  to  the  Valley  of  Death 


C.  DOD’S  DEEPER  VALLEY  AND  WIDER  TROUGH 

The  US  Defense  Enterprise  began  eontinuous  and  signifieant  investment  in  seientifie 
research  and  associated  engineering  early  in  the  twentieth  century.  Radar,  sonar,  the 
atomic  bomb,  GPS,  TCP/IP,  and  the  search  engine  are  examples  of  the  technologies  that 
transitioned  from  this  Defense  investment.  The  continuing  Defense  investment  in 
technology  discovery  is  called  the  “Science  and  Technology”  (S&T)  process. 

The  Defense  Enterprise  can  follow  essentially  two  paths  to  tech  transition.  Intellectual 
Property  (IP)  developed  at  government  expense  can  transitions  via  direct 
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commercialization.  It  can  also  transition  via  the  “Program  of  Record”  (POR)  wherein 
Defense  Systems  get  built  with  government-developed  IP.  The  Federal  Acquisition 
Regulations  (FAR)  mandate  that  government  programs  leverage  Commercial-off-the- 
Shelf  (COTS)  technology  whenever  possible.  The  FAR  further  encourages  that  IP 
developed  at  government  expense  be  made  as  widely  available  to  the  public  as  possible. 
(US  Federal  Government)  The  implication  is  that  transition  via  direct  commercialization 
is  preferred.  However  the  two  paths  to  transition  are  not  necessarily  mutually  exclusive. 
POR’s  can  certainly  transition  technology  by  investing  in  commercial  firms  to  evolve 
generic  COTS  products  that  address  requirements  for  Defense  systems.  Indeed,  that 
often  happens  as  a  stopgap  measure  necessitated  by  schedule  and  budget  over  runs,  or 
emergencies.  In  these  cases  effective  transition  occurs  essentially  by  accident,  without  a 
strategy  for  continuously  refreshing  the  COTS. 

Famous  historical  successes  and  accidental  opportunities  at  tech  transition  not 
withstanding,  in  general  the  Valley  of  Death  plagues  the  Defense  acquisition  process. 
(National  Research  Council,  2004)  Defense  programs’  tend  to  invest  in  information 
technologies  while  they  are  still  near  the  top  of  the  Hype  Curve.  That  tendency 
contributes  to  the  issue.  (GAO,  2006)  Watchdog  reports  have  suggested  changes  to  the 
Defense  acquisition  process  to  better  cope  with  the  rapid  evolution  of  IT.  (Defense 
Science  Board,  2009)  Many  Defense  and  other  government  offices  have  responded  with 
enlightened  policies  that  aim  to  adapt  commercial  best  practices  for  rapid,  evolutionary, 
development.  (Office  of  the  Secretary  of  Defense,  2010)  These  intentions 
notwithstanding,  so  far  success  has  been  limited.  (Powner,  2014)  In  particular,  DoD  has 
acknowledged  that  it  is  generally  unable  to  implement  its  envisioned  rapid,  incremental 
delivery  of  IT-enabled  capability.  (GAO,  2014) 

DoD’s  process  for  spanning  the  Valley  of  Death  via  POR  is  called  the  “Acquisition 
System.”  In  this  system,  a  POR  proceeds  serially  from  “Research  and  Material  Solution 
Analysis”  through  “Milestone  A”  (MS  A)  into  “Technology  Development”  for  risk 
reduction.  The  process  continues  through  “MS  B”  into  “Engineering  &  Manufacturing 
Development”  through  “MS  C”.  “Operational  Test  &  Evaluation”  (OT&E),  and 
Interoperability  Testing  follow  MS  C  and  precede  “Production  and  Deployment.  ”  Initial 
Operating  Capability  (IOC)  is  next,  followed  by  “Operations  and  Support.”  (Department 
of  Defense  (DoD),  2013)  (See  figure:  2)  The  end-to-end  process  takes  years  and  is 
subject  to  frequent  cost  and  schedule  over  runs,  and  re-baselining.  (Department  of 
Defense,  2014) 

The  DoD  acquisition  process  includes  differing  categories  of  funds,  each  with  its  own 
strict  fiscal  governance.  Research  and  Development,  Test  and  Evaluation  (RDT&E) 
funds  are  used  generally  for  discovery,  prototype  development  and  risk  reduction. 
Procurement  funds  are  used  generally  to  develop  and  manufacture  delivered  capability. 
Operations  and  Maintenance  (O&M)  funds  are  used  to  sustain  delivered  capability. 
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Documentation  for  each  milestone  decision  takes  a  long  time  to  develop  and  is 
expensive.  It  tends  to  be  redundant  across  programs,  especially  for  information 
systems.  Why  not  automate  across  the  Defense  Enterprise  per  Computer  Assisted 
Design  (CAD)  for  engineering,  and  TurboTax  for  compliance? 
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1-2  years  for  Information  Assurance  (lA)  Certification  and 
Accreditation  (C&A).  Every  time  IT  is  refreshed,  C&A  must  also 
be  refreshed.  C&A  artifacts  do  not  transfer  across  systems. 
How  about  an  open  standard  virtual  security  layer? 


Figure  2:  Basic  components  (comments  are  the  author’s)  of  the  Defense  acquisition  system  from  2013 
interim  guidance  pending  new  policy 

Theoretically,  technology  developed  via  the  S&T  process  may  enter  the  FOR  Acquisition 
System  at  any  point  in  the  process,  however  it  typically  enters  during  the  Technology 
Maturation  and  Risk  Reduction  phase.  Practitioners  within  the  S&T  process  often  equate 
transfer  of  their  technology  to  the  FOR  as  “transition.”  (US  GAO,  2013)  However,  that 
technology  can  only  become  usefully  adopted  if  and  when  the  FOR  reaches  the 
Operations  and  Support  phase,  usually  years  later. 

Any  information  processing  capability  developed  for  the  Defense  enterprise  must 
undergo  a  Certification  and  Accreditation  (C&A)^  process  for  Information  Assurance 
(lA)  before  it  can  be  made  operational.  C&A  is  the  purview  of  the  Designated 
Approving  Authority  (DAA)  associated  with  the  device,  system,  and/or  environment  of 
interest.  C&A  is  a  largely  non-standard  process  that  occurs  prior  to  “Operations  and 
Support”  and  typically  takes  more  than  a  year  to  complete  for  well-understood 
technologies.  For  innovative  or  disruptive  technologies,  the  process  can  take  several 
years.  C&A  updates  are  required  whenever  significant  tech  refreshes  occur  across  the 
lifecycle  of  the  capability.  If  an  IT-intensive  systems  is  to  remain  relevant,  it  must 
undergo  frequent  tech  refresh. 


*  Per  DoD  Instruction  8510.01,  dated  12  March  14,  the  term  C&A  will  be  replaced  by  “Assessment  and 
Authorization  “(AA)  and  the  term  DAA  will  be  replaced  by  “Authorizing  Official”  (AO).  Legacy  terms 
are  used  here  because  they  are  still  in  common  use  as  of  the  date  of  this  paper. 
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DoD  officials  recognize  that  the  proeess  deseribed  above  is  not  optimized  for  information 
systems.  Aceordingly,  the  latest  update  to  the  DoD  Aequisition  System  poliey  helpfully 
suggests  streamlining  the  transition  proeess  for  “Software  Intensive”  programs,  and  for 
“Aeeelerated  Aequisition  Programs.”  The  streamlining  ealls  for  exeeuting  multiple 
software  builds  between  MS  B  and  MS  C.  That  means  that  the  iterative  software 
development  aetivity  is  preeeded  by  the  legaey  AoA  and  requirements  development 
proeess  prior  to  MS  A,  and  followed  by  legaey  operational  testing  and  C&A  that  oecurs 
after  MS  B.  (Department  of  Defense  (DoD),  2013)  In  other  words,  even  in  this 
streamlined  version,  software  development  is  inserted  in  the  middle  of  a  paper-intensive, 
serial  verifieation  proeess,  based  on  criteria  originally  developed  for  traditional  hardware. 
(See  figure:  4)  Henee  the  DoD  Aequisition  System  still  does  not  lend  itself  to  rapid 
ineremental  transition  of  new  IT.  (GAO,  2014) 

Meanwhile,  Defense  aequisition  poliey  reeognizes  that  the  proeess  for  post  IOC  lifeeycle 
sustainment  of  a  software-intensive  eapability  requires  eontinuous  teeh  refresh.  This 
requirement  is  relentlessly  driven  by  the  faet  that  the  original  hardware  and  software 
quickly  become  unavailable  from  the  Original  Equipment  Manufacturer  (OEM.)  In  other 
words  “sustaining”  IT  really  means  eontinually  improving  it  as  suggested  by  Moore’s 
Eaw,  not  just  fixing  it  when  it  breaks.  Therefore,  the  sustainment  phase,  whieh  oeeurs 
after  IOC,  requires  defining  requirements,  AoA,  risk  reduetion,  engineering  & 
manufacturing  development,  T&E,  and  C&A.  These  are  preeisely  the  same  aetivities 
required  before  IOC! 

However  in  the  sustainment  phase,  O&M  funds,  rather  than  RDT&E  or  procurement 
funds,  are  generally  used  to  execute  these  aetivities.  Per  the  PAR,  O&M  funds  must  be 
exeeuted  in  their  budget  year.  They  may  not  be  used  for  researeh  and  development  or 
major  proeurements.  Typieally,  therefore,  O&M  funds  used  to  sustain  equipment  are 
executed  via  eontraets  for  COTS  produets  and  services.  Aceordingly,  Defense 
aequisition  poliey  for  eapability  sustainment  is  to  apply  commercial  best  practices. 

(DAU)  Consistent  with  that  poliey,  best  eommereial  praetiee  for  teeh  refresh  of 
information  systems  ineludes  rapid,  parallel  iteration  of  the  following  proeesses: 

•  Continuous  feedback  to-from  operational  customers  to  evolve  requirements 
in  concert  with  evolving  technology 

•  Disciplined  application  of  objective  and  testable,  tightly  coupled,  Measures  of 
Effectiveness,  Performance,  and  Suitability. 

•  Reuse  of  best-of-breed  lifecycle  supported,  open  standard,  pre-approved,  off- 
the-shelf  capability 

•  Performance-test-based  AoA  and  source  selection  for  risk  reduction 

•  Pre-negotiated,  performance-based,  contracting 

•  Streamlining  C&A  via  re-use  of  previously  developed  artifacts 

Note  that  government  officials  must  manage  all  those  O&M  post-IOC  tech  refresh 
activities  according  to  the  same  Eederal  Aequisition  Regulation  (PAR)  that  governs 
material  development  prior  to  IOC. 
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D,  BUILDING  BLOCKS  FOR  THE  BRIDGE 


Per  discussion  above,  Christensen’s  insight  along  with  study  of  the  many  successful  and 
failed  transitional  efforts  suggests  some  universal  patterns  of  success.  The  following 
general  recommendations  are  based  on  those  patterns. 

The  best  first  step  for  transitioning  an  invention  is  to  quickly  wrap  it  in  a  utility  that 
makes  life  easier  or  cheaper  for  a  specific  customer  group.  Focus  on  making  the 
application  useful,  not  hyping  the  enabling  technology. 

Government  furnished  IP  is  a  powerful  catalyst  for  industrial  innovation.  The  best 
practice  is  to  deliberately  “open  source”  government  IP  rights  as  “Government  Furnished 
Equipment”  (GFE)  available  broadly  to  industry.  Require  vendors  who  are  paid  to 
develop  IP  at  government  expense  to  employ  appropriate  licenses  and  data  rights  models 
to  deliver  capability  via  artifacts  that  can  be  wrapped  as  GEE. 

Industrial  innovation  is  a  powerful  force  multiplier  for  government  acquisition  objectives. 
The  best  practice  is  to  incentivize  COTS  industry  to  satisfy  government  requirements 
with  their  generic  product  lines.  Employ  acquisition  strategies  that  build  with  generic 
COTS  components  rather  than  develop  specialized  capabilities  via  so  called  “commercial 
standards”. 

Standards  can  be  catalysts  for  tech  transition,  but  only  if  they  either  already  exist,  or  if 
they  evolve  as  a  result  of  actual  adoption.  Top  down  efforts  to  mandate  creation  of 
standards  in  order  to  transition  technology  simply  don’t  succeed.  The  best  practice  is  to 
implement  mature  commercial  open  standards  for  interfaces  between  productized 
functional  capabilities.  Require  new  functional  inventions  to  interface  via  those 
specified  functioning  open  standards.  In  other  words  encourage  creativity  and  production 
within  functional  “boxes”  in  the  system  design.  Require  compliance  with  the  specified 
mature  and  already  functioning  standard  interface  “lines”  between  the  functional  boxes. 

If  the  newly  invented  functional  capability  becomes  widely  adopted,  its  standardization 
will  follow.  (See  Eigure:  3) 

E.  SUCCESS  DEFINED 

Applying  these  concepts  to  a  the  Defense  acquisition  system  leads  to  the  following  set  of 
conditions  that  define  successful  tech  transition: 

•  Owner  of  new  capability  is  identified 

•  Funds  are  available  to  procure  and  sustain  the  new  capability. 

•  Prototyped  new  capability  has  been  demonstrated  to  interface  usefully  to 
legacy  architecture. 

•  New  capability  satisfies  threshold  operational,  system,  and  process 
requirements 
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•  Lifecycle  support  model,  including  government’s  IP  rights,  is  specified 

•  Capability  is  certified  and  accredited  for  functionality,  safety, 
interoperability,  and  security 

•  Funding  authority  approves  allocation  of  funds. 

•  Convenient  contract  vehicle(s)  exist(s)  and  governs  lifecycle  activities  of 
capability. 

•  Capability  delivered  and  functions  to  threshold  level  in  target  environment. 

•  Capability  successfully  undergoes  at  least  one  iteration  of  lifecycle  support. 


Historically,  the  government  has  aehieved  these  conditions,  intentionally  or 
unintentionally,  through  one  of  these  three  approaehes: 

•  Government  procurement  of  purely  commercial  offerings. 

•  Government-industry  partnerships  for  tech  transition  via  deliberate 
commercialization. 

•  Government  acquisition  programs  designed  to  develop  government-specific 
capability. 

These  options  are  listed  in  order  of  the  Government’s  preference,  i.e.  as  previously 
explained,  laws  and  regulations  mandate  that  government  proeurement  should  support 
and  not  compete  with  commereial  industry.  (US  Federal  Government) 
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VI.  THE  BRIDGE  DESIGN:  PRODUCT  LINE 
ARCHITECTURE 


Product  Line  Architecture  (PLA)  is  a  disruptive  invention  that  helped  transform  the 
WWW,  as  well  as  other  communications  platforms,  into  the  rapidly  evolving  commercial 
ecosystem  they  have  become.  PLA  is  the  set  of  IT  design  characteristic  and 
implementation  processes  at  the  intersection  of  an  enterprise’s  e-business  model,  and  its 
open  standard  IT  platform.  PLA  aims  to  optimize  the  latter  to  achieve  the  former.  Both 
Mac  and  Windows,  for  example,  apply  PLA  very  effectively  within  their  respective  IT 
device  product  lines. 


PLA  imposes  the  discipline  necessary  to  prevent  the  “verticals,”  i.e.  the  product 
providers,  in  an  enterprise  from  competing  with  each  other  on  the  basis  of  proprietary 
“horizontal”  infrastructure.  Correspondingly,  PLA  provides  consumers  with  a  single 
point  of  access  to  the  entire  suite  of  e-products  provisioned  by  the  enterprise  of  interest. 
PLA  thus  supports  rapid  speed-to-capability  for  initial  capability,  lifecycle  refresh,  and 
extending  the  scope  of  capability.  It  also  enables  decreased  cost-per-capability  through 
simplified  integration  and  reuse  of  existing  capabilities. 

For  reference,  please  see  the  body  of  work  by  Carnegie  Mellon  University  (CMU) 
Software  Engineering  Institute  (SEI)  that  thoroughly  explains  and  describes  “Software 
Product  Eines”  (SPE)  in  context  with  multiple  real  world  use  cases.  (CMU  SEI).  SPL  are 
essential  building  blocks  for  the  broader  concept  of  PEA. 

Although  the  term  PLA  has  often  been  associated  with  relatively  narrowly  defined 
enterprise  software  frameworks  such  as  Mac  or  Windows,  or  telecommunications 
platforms  such  as  Nokia,  the  same  concept  can  be  applied  more  abstractly  to  more 
loosely  defined  and  more  federated  Enterprise  Information  Systems  (EIS).  Arguably,  for 
example,  the  eEile  standards  and  policies  governed  by  the  Internal  Revenue  Service  (IRS) 
represent  a  PLA  of  sorts.  In  any  case,  PLA  is  a  disruptive  invention  designed  to 
accelerate  the  transition  of  disruptive  software  inventions.  Eor  example,  TurboTax 
represents  a  technology  that  transitioned  via  the  IRS’s  ePile  PEA,  and  profoundly 
disrupted  the  tax  filing  and  collecting  ecosystem. 
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Figure  3:  Product  Liue  Architecture  provides  a  platform  to  trausitiou  iuveutious  immediately  to 
adoptiou.  Successful  uew  compoueuts  ofteu  evolve  to  become  elemeuts  of  iufrastructure 
Clearly  the  digital  camera  is  a  disruptive  technology.  Much  of  its  disruptive  influence 
was  manifested  when  the  camera-as-a-component  was  incorporated  into  PLA  for  IT 
devices  like  smart  phones  and  tablets.  The  camera  in  an  IT  device  consumes  standard 
power,  and  transmits  standard  digital  image  data,  via  specified  standard  interfaces, 
according  to  a  pre-negotiated  standard  intellectual  property  rights  model,  business  model, 
security  model,  and  lifecycle  support  models.  All  the  downstream  innovations  that 
consume  the  standard  digital  image,  e.g.  instant  messaging.  Facetime,  etc.,  are 
constrained  on  the  back  end,  and  accelerated  to  market  on  the  front  end,  by  the  same 
PLA.  Significantly,  much  of  the  disruptive  influence  of  the  Defense-developed,  Global 
Positioning  System  (GPS)  was  manifested  via  the  same,  purely  commercial,  process. 

Achieving  the  potentially  catalytic  benefits  of  PLA  requires  provisioning  a  suite  of  PLA- 
derived  tools  and  processes  to  developers.  The  PLA  suite’s  aim  is  to  streamline  and 
parallelize  the  myriad  activities  associated  with  transitioning  IT  inventions  into 
operations.  Here  are  some  of  those  PLA  utilities  for  rapid,  iterative,  parallel  developing, 
testing,  certifying,  offering,  consuming,  and  refreshing  capability: 

•  Bottom  up  process,  informed  by  customer-in-the-loop,  for  continuously 
adapting  emerging  standards  against  enterprise  functional  and  performance 
specifications. 
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•  Persistent,  open,  online  "plug  test"  PLA  Reference  Implementation  (Rl)  for 
developing,  testing,  and  certifying  inventions.  Includes  an  evolving  library  of 
documented  PLA-compliant  components,  developers’  guides,  and  Software 
Development  Kits  (SDK). 

•  Certification  requirements  for  security  and  interoperability  are  embedded  in 
the  technical  guidance  and  the  Rl  so  that  successfully  compiled  offerings 
inherit  certification  controls  from  the  enterprise  framework  itself. 

•  Pre-negotiated  contractual  vehicles  that  address  compensation  and 
obligations  to  all  parties,  including  intellectual  property  rights. 


Note  that  Apple,  Microsoft,  Google,  Android,  etc.  provision  these  PLA  utilities  to  a  huge 
global  community  of  potential  innovators.  They  do  that  via  convenient  resources 
available  through  open  standard  developers’  portals  at  Apps  Stores  and  similar  online 
venues.  These  enterprises  thereby  crowd  source  technology  transition  by  exposing  a 
convenient  transition  path  to  their  enterprise  product  lines.  That  is,  the  PLA-based 
developers’  portal  makes  typically  difficult  activities  —  such  as  Analysis  of  Alternatives 
(AoA),  prototyping,  iterative  development,  test  and  evaluation,  certification,  production, 
delivery,  and  lifecycle  support  —relatively  easy  and  inexpensive  to  perform. 

This  “apps-store”  transition  model  lends  itself  uniquely  to  the  highly  abstract  nature  of 
software.  Unlike  any  other  product  type,  developers  always  deploy  software  knowing 
that  it  is  flawed.  Continually  collecting  and  acting  on  user  feedback  to  rapidly  fix  and 
enhance  the  previous  iteration  mitigates  the  risk  associated  with  “buggy”  software 
releases.  This  paradigm  greatly  decreases  the  time  and  cost  of  “manufacturing 
development”  that  traditionally  follows  demonstrations  and  tests  of  hardware  prototypes. 

In  this  sense,  the  online  PLA  portal  provides  a  virtual  laboratory  for  developing  the 
invention,  and  a  channel  to  market  to  transition  the  innovation.  When  the  invention 
functions  properly  in  the  lab,  it  can  transition  as  a  certified,  lifecycle-sustained,  product 
that  can  be  immediately  lucrative  for  both  the  provider  and  consumer.  If  the  invention 
fails  to  be  adopted,  it  fails  fast  and  cheap,  with  feedback  for  the  next  try. 

Not  surprisingly,  the  PLA  utilities  enumerated  above  align  very  well  with  the  COTS  best 
practices  that  Defense  acquisition  policy  suggests  are  appropriate  for  sustainment  of 
software  intensive  capability  explained  previously.  Further,  procurement  of  COTS 
products  and  services  as  a  means  to  satisfy  government  requirements  is  not  only  legal,  the 
FAR  explicitly  favors  that  approach.  Finally,  the  recently  implemented  “IT  Box”  option 
for  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  prescribes  a  COTS- 
friendly  software  development  process  for  some  narrowly  defined  programs.  (Joint 
Chiefs  of  Staff,  2012) 

Both  the  RDT&E  and  Procurement  funds  executed  prior  to  IOC  may  legally  be  used  to 
contract  with  COTS  providers,  and  to  purchase  COTS  end  items.  (DoD,  2000)  Again, 
the  JCIDS  IT  Box  guidance,  which  is  applicable  to  some  FAR-compliant  Defense 
programs,  is  well  aligned  with  the  COTS  PLA  best  practices.  Therefore,  there  is  no 
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statutory  barrier  to  using  the  COTS  best  practiees  mandated  for  post  IOC  lifeeycle 
support  for  all  development  aetivities  prior  to  IOC.  Rather,  the  barrier  is  the  arbitrary 
assumption  that  software  development  requirements  for  various  elasses  of  modern 
systems  are  fundamentally  different  from  eaeh  other.  Making  arbitrary  assumptions 
about  requirements  is  not  consistent  with  good  systems  engineering. 
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VII.  EINSTEINIEN  ACTION 


According  to  popular  lore,  Einstein  explained  that  the  same  thinking,  people,  and 
proeesses  that  ereated  a  problem  are  unlikely  to  solve  it.  His  adviee  was  to  find  a 
fundamentally  different  approaeh.  The  Defense  enterprise  has  been  working  hard  to 
bridge  the  IT  transition  gap  for  two  deeades,  more  or  less.  All  the  points  raised  above 
have  been  raised  before.  Indeed,  dedieated  people  in  the  Defense  enterprise  have  taken 
intelligent  action  consistent  with  these  arguments.  However,  the  implementation 
methodologies  typieally  do  not  heed  Einstein’s  warning.  That  is,  professionals  in  the 
Defense  Enterprise  elearly  understand  the  desired  to-be  end  state.  They  also  understand 
the  deficiencies  assoeiated  with  the  as-is  status  quo.  The  issue  has  been  trying  to  elose 
the  gap  between  the  as-is  and  to-be  by  using  the  Pentagon  proeesses  that  ereated  the 
defieieneies  in  the  first  plaee.  The  following  reeommendations  embraee  Einstein’s  adviee 
by  applying  Christensen’s  prineiples  for  implementing  disruptive  inventions  via  PEA. 

A,  INCENTIVIZE  OPEN  SYSTEM  APPROACH 

Eor  decades.  Defense  policy  has  mandated  eomplianee  with  standards.  The  implication  is 
that  complying  with  standards  will  naturally  lead  to  interoperability  and  assoeiated 
effieieneies.  However,  complying  with  standards  as  an  objective  in  and  of  itself  has  not 
led  to  the  hoped-for  interoperability  or  assoeiated  efficiencies.  Eikewise,  implementing 
new  teehnology  because  it  is  new  is  a  failed  strategy.  In  eontrast,  PEA  speeifies 
standards  as  boundary  eonditions.  Teehnologies,  new  or  otherwise,  are  implemented  if 
and  only  if  they  measurably  improve  targeted  business  outeomes.  In  this  way, 
eomplianee  with  enterprise  PEA  earns  a  metaphorieal  “Good  Housekeeping  Seal  of 
Approval.”  The  PEA  “logo”  beeomes  a  luerative  market  differentiator. 

The  Einsteinien  paradigm  shift  is  to  implement  open  standard  approaehes  within  the 
broader  business  objectives  of  disciplined  enterprise  PEA.  Certainly  require  that 
eomponent  solution  providers  comply  with  technical  standards  for  interoperability. 
However,  don’t  test  only  for  standard  eomplianee.  Test  also  for  functionality,  and 
mission  performance  enhaneement.  Contraetually  provide  for  an  online  feedbaek  loop 
with  operational  customers  of  the  delivered  eapability.  Provide  a  clear  open  IP  poliey 
agreement,  and  require  that  solution  providers  sign  up.  Demand  elear  explanation  of  the 
evolutionary  lifeeyele  support  proeesses  assoeiated  with  any  approved  solution.  Develop, 
publish,  and  implement  need-to-share  security  and/or  privacy  policies.  Reward 
eomplianee  with  PEA  standards  and  business  agreements  with  PEA  eertification  “logo.” 
Assoeiate  the  logo  with  front-end  loaded  lieense  and  eontraet  agreements  that  represent 
eonvenient  pre-negotiated  approvals  from  eontraeting  offieers  and  eertifieation 
authorities.  Publish  a  catalog  of  logoed  offerings  and  assoeiated  proeurement  vehieles. 
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B,  MEASURE  THE  RIGHT  THINGS 

“You  get  what  you  measure!”  A  basic  tenant  of  effective  management  is  to  measure  the 
things  that  matter,  and  react  accordingly.  Defense  acquisition  projects  measure 
compliance  in  terms  of  paperwork  submitted.  They  also  measure  “Earned  Value” 
defined  as  “contractually  required  activities  completed  on  time  and  schedule.”  The  most 
successful  commercial  enterprises,  by  contrast,  measure  the  time  and  cost  of  compliance 
in  order  to  streamline  compliance.  They  also  measure  the  margin  between  cost  and  value 
in  order  to  maximize  return  on  investment. 

The  Einsteinien  paradigm  shift  is  to  employ  testable,  system-level  and  process-level 
Measures  of  Performance  (MOP)  that  are  tightly  coupled  to  operational-level  Measures 
of  Effectiveness  (MOP).  These  metrics  should  objectively  define:  capability  outcome 
requirements,  cost-per-capability,  speed-to-capability,  and  predictability  of  cost, 
performance,  and  schedule.  (Gunderson  C.  R.,  2014)  Establish  baseline  values  and 
objective  V&V  techniques  that  assure  that  business  objectives  are  properly  represented 
by  MOE.  Rigorously  verify  that  achieving  improved  MOP  indeed  leads  to  improving 
MOE.  Build  this  V&V  capability  into  an  instrumented,  persistent,  PlugTest 
environment.  (Gunderson  &  Minton,  Rapid  Evolutionary  Acquisition:  An  In  Progress 
Review  of  an  Exemplar  Pilot  Initiative,  2011) 

C.  PAY  FOR  THE  RIGHT  THINGS  THE  RIGHT  WAY 


“You  get  what  you  pay  for!”  The  government  pays  for  things  by  contracting.  The  stated 
reason  for  why  government  contracting  is  usually  rigid,  expensive,  and  takes  a  long  time 
is  to  “reduce  risk”.  Risk  in  traditional  government  contracting  is  indeed  low  in  the  sense 
that  contractors  by  and  large  comply  with  the  requirements  of  their  contracts.  That  is,  the 
government  generally  accepts  contract  deliverables.  Nevertheless,  the  Defense 
acquisition  process  is  not  sufficiently  successful  when  measured  against  enterprise  goals 
and  objectives.  Therefore,  by  definition.  Defense  acquisition  system  contracts  are  not 
paying  for  the  right  things. 

One  Einsteinien  paradigm  shift  is  to  use  the  value-based  metrics  described  above  as  basis 
for  EIS  contract  award  and  incentives.  Use  published  project  budgets,  schedules,  use 
cases  (including  MOE,  MOP),  and  associated  test  cases,  in  lieu  of  traditional 
solicitations.  Use  an  instrumented  PEA  Plug  Test  environment  as  the  platform  for  V&V 
of  compliance,  functionality,  and  performance  in  lieu  of  review  of  written  claims. 

Another  Einsteinien  change  is  to  employ  rapid,  adaptive,  procurement  vehicles.  These 
vehicles  should  be  pre -negotiated  and  allow  flexible-award.  The  vehicle  should  allow 
closely  aligned  use  of  the  same  COTS  software  lifecycle  processes  for  research, 
procurement,  and  tech  refresh  of  capability.  Employ  the  inherent  innovative  potential  of 
Other  Transaction  Agreements  (OTA)  (Cassidy,  Putsch,  &  Barclay,  2013),  in  lieu  of,  in 
combination  with,  and  in  order  to  evolve  improved  versions  of,  traditional  contracts. 
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D. 


VIRTUALIZE  AND  STANDARDIZE  SECURITY 


Security  requirements  have  historically  stymied  efforts  to  both  accelerate  development  of 
information  systems,  and  establish  interoperability  across  systems.  In  response,  new 
Defense  policies  demand  that  security  strategies  address  need-to-share  data  and  resources 
in  balance  with  the  traditional  need-to-protect.  New  policy  also  requires  that  the  various 
C&A  authorities  agree  to  reciprocity  of  C&A  artifacts  across  their  respective  domains. 
However,  traditional  security  models  are  based  on  physical  separation,  sharing  across 
boundaries  creates  vulnerability  by  definition.  Traditional  security  technologies  are  not 
standard,  and  tend  to  be  tuned  to  the  requirements  of  a  particular  stovepipe  system. 
Modern  IT  architectures,  e.g.  cloud,  are  based  on  logical  separation.  However,  traditional 
C&A  arguments  do  not  recognize  logical  separation.  (Gunderson,  2014) 

The  Einsteinien  paradigm  shift  is  to  convert  security  compliance  from  a  necessary  evil  to 
a  value  added  moneymaker.  Use  virtual  technologies  to  establish  assured  logical 
separation  within  an  open  standard  “security  layer”  of  the  enterprise  PLA.  Develop 
associated  new  C&A  assurance  arguments.  Use  metaphors  from  traditional  physical 
separation  arguments  to  explain  how  the  technologies  that  are  logically  “above”  the 
security  layer  can  inherit  the  security  controls  provided  by  the  logical  separation.  Start 
with  low  risk,  but  important  use  cases  that  have  strong  political  support.  Use  the 
commercial  IT  marketplace  to  expose  requirements,  government-developed  IP,  and 
explanation  of  the  opportunity  to  industry  at  large.  Demonstrate  improved  capability-per- 
cost,  and  speed-to-capability  possible  via  this  dynamic,  virtual  approach. 

E,  MANAGE  TECH  TRANSITION  IN  A  BROWN  FIELD 

A  green  field  project  is  one  that  is  not  constrained  by  prior  work.  A  brown  field  project 
recognizes  that  starting  fresh  is  an  unaffordable  luxury.  (Hopkins,  2008)  Typically 
government  acquisition  efforts  are  framed  within  stove-piped  funding  models. 
Accordingly,  they  favor  re-invention  within  the  stovepipe  over  reuse  across  the 
stovepipes.  This  is  a  classic  green  field  approach  wherein  re-invention  wastes  time  and 
resources. 

The  Einsteinien  paradigm  shift  is  to  contractually  identify  existing  commercial  and 
government  computer  networks  and  components  that  might  belong  to  other  programs  as 
GEE.  Project  management  plans  including  incentives,  risks,  and  test  and  C&A  strategies 
should  specifically  address  either  how  the  externally  furnished  infrastructure  will  be 
measurably  leveraged,  or  explain  why  it  must  written  off  as  an  abandoned  sunk  cost. 

This  approach  will  force  stovepipe  projects  to  build  toward  a,  mutually  “pluggable” 
horizontal  platform  going  forward. 
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F,  AUTOMATE  DESIGN,  ENGINEERING  WORKFLOW,  AND 

COMPLIANCE 


The  technical  requirements,  design  constraints,  and  potential  solution  options  for 
information  systems  that  support  even  diverse  use  cases  are  likely  to  be  highly  redundant. 
Further,  as  explained  above,  planned  re-use  of  existing  computer  network  infrastructure 
should  be  included  in  any  new  information  system  development.  Nevertheless,  Defense 
EIS  projects  tend  to  start  from  scratch  with  respect  to  both  designing,  and  documenting 
compliance  of  the  design.  For  example,  the  serial,  paperwork  required  by  the  Joint 
Capability  Integration  Development  System  (JCIDS)  is  highly  redundant.  Yet,  each  new 
EIS  program  that  enters  the  JCIDS  process  spends  millions  of  dollars  and  takes  years  to 
reproduce  it. 

Meanwhile  there  are  certainly  tools  for  automating  design,  workflow,  and  compliance 
that  have  effectively  streamlined  JCIDS-like  processes  in  other  domains.  Eor  example 
Computer  Assisted  Design  (CAD)  has  vastly  decreased  the  architecting  and  engineering 
time  and  cost  of  various  classes  of  systems.  TurboTax  and  similar  tools  have  vastly 
decreased  time  and  cost  of  complying  with  complex  tax  code,  while  maximizing  the 
business  objectives  of  the  fder. 

The  Einsteinien  paradigm  shift  is  to  apply  the  TurboTax  and  CAD  paradigm  and  enabling 
technologies  to  develop  expert  systems  that  automate  and  streamline  the  Defense 
acquisition  system.  Expert  systems  like  TurboTax  puts  detailed  compliance  requirements 
“under  the  hood.”  CAD  likewise  puts  details  of  technical  standards,  design  constraints, 
and  available  solutions  under-the-hood.  User-friendly  menus  narrow  the  options. 
Semantic  algorithms  front-end-load  the  options  that  are  most  likely  to  be  the  most 
beneficial.  The  expert  system  “learns”  over  time.  Automated  workflow  tools  can 
distribute  these  functions  across  work  centers. 

Similar  technology  can  provide  similar  automated  expert  assistance  for  engineering 
OEIS,  while  complying  with  JCIDS  in  the  process.  Eor  example,  the  Marine  Corps 
Combat  Development  Center  demonstrated  the  viability  of  this  methodology  via  the 
Semantically  Informed,  Dynamic  Engineering  of  Capabilities  and  Requirements 
(SIDECAR)  prototype.  (Eenet,  et  ah,  2010).) 
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The  latest  Defense  Acquisition  System  interim  guidance  takes  a  step  in  the  right 
direction  by  recognizing  the  need  to  do  iterative  software  development,  but.... 


Upfront  AoA  and  requirement  V&V  is  still  based  on  expensive,  time  consuming  paperwork. 


locked  in  contractors.  software  development  process? 

Figure  4:  Diagram  from  2013  interim  guidance  for  Defense  acquisition  system  (comments  are  the 
author's.)  This  approach  inserts  the  "square  peg"  of  iterative  software  development  in  the  round 
hole  of  a  traditional  waterfall  model 

G.  MOVE  FROM  MONOPOLY  TO  MARKET 

Defense  policy  recognizes  that  IT,  and  software  in  particular,  are  critically  important  to 
virtually  all  material  acquisitions.  Nevertheless,  efforts  to  improve  Defense  IT 
acquisition,  rather  arbitrarily,  identify  only  certain  categories  of  projects,  e.g.  “business 
systems”  rather  than  “weapon  systems,”  as  appropriate  for  application  of  commercial  best 
practices  for  IT.  One  implied  assumption  is  that  software  development  requirements  for 
weapon  or  intelligence  applications  are  fundamentally  different  than  for  financial  or 
personnel  applications.  Another  implied  assumption  is  that  the  software  requirements  for 
Defense  applications  within  one  program  are  fundamentally  different  than  software 
requirements  for  similar  applications  in  other  programs. 

The  basis  for  these  assumptions  is  not  clear.  There  are  only  so  many  ways  to  process 
data,  and  the  digital  zeroes  and  ones  don’t  care  why  the  data  is  being  processed. 
Regardless,  the  software  development  requirements  for  a  given  Defense  FOR  are 
addressed  by  the  small  monopoly  and  associated  shallow  creative  gene  pool  represented 
by  its  locked-in  Defense  contractor  team.  Further,  these  software  development 
requirements  are  addressed  in  the  Defense  acquisition  serial  process  between  milestones 
B  and  C.  Hence,  it  is  impossible  for  the  isolated,  time-boxed.  Defense  acquisition 
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software  development  proeess  to  keep  up  with  the  rapid  evolution  of  IT  in  the  rest  of  the 
world. 

The  rapid  evolution  of  IT  in  the  rest  of  the  world  is  due  largely  to  the  massive  crowd 
sourcing  of  global  entrepreneurial  creativity  to  business  opportunities  exposed  in  the 
COTS  IT  marketplace.  Enterprises  that  expose  a  problem  and  a  budget  to  the 
marketplace  are  rewarded  with  many  inventive  potential  solutions  from  multiple  sources. 
These  potential  solutions  are  often  in  the  form  of  already  functioning  inventions 
developed  at  the  inventors’  expense. 

The  Einsteinien  paradigm  shift  is  to  abstract  the  software  development  component  of 
Defense  acquisition  projects  away  from  the  serial  waterfall  acquisition  process.  Use  the 
same,  continuous,  rapid,  adaptive,  software  development  process  as  a  critical  aspect  of  all 
phases  of  the  Defense  acquisition  process,  AoA,  risk-reduction,  development,  production, 
test,  certification,  procurement,  and  life  cycle  tech  refresh.  Perform  all  these  activities 
continuously  in  parallel  across  the  lifecycle  of  a  project. 

Consider  software  development  to  be  a  critical  enterprise  concern  across  all  Defense 
investments.  That  is,  the  software  development  requirements  for  all  Defense  programs 
should  be  exposed  to  the  same  marketplace.  Don’t  make  arbitrary  distinctions  based  on 
category  of  system.  Requirements  are  requirements.  Even  if  a  weapon  system’s 
requirements  at  the  digital  level  actually  are  different  than  a  business  system’s 
requirements,  the  marketplace  is  still  the  best  way  to  address  all  but  the  most  specialized 
of  them.  Classified  nuance  can  often  be  addressed  after  source  selection  based  on  a 
generic  solicitation. 

Eeverage  competition  and  economy  of  scale  by  incentivizing  a  Defense  IT  marketplace 
that  is  literally  a  subset,  rather  than  a  duplicate,  of  the  broad  global  IT  marketplace.  The 
Defense  Enterprise  often  attempts  to  replicate  commercial  processes  rather  join  them. 
Examples  include:  Defense  Travel  Service  (DTS)  vs.  Travelocity;  Eorge.Mil  vs. 
SourceEorge;  DoD  IT  Standards  Registry  (DISR)  vs.  Open  International  IT  Standards 
Bodies.  However,  creating  a  relatively  small  duplicate  of  some  aspect  of  a  huge  global 
market,  e.g.  a  CAC-card  protected  Apps  Store  for  GOTS,  is  not  the  same  thing  as  staking 
out  a  claim  within  the  huge  global  market,  e.g.  Apple  Apps  Store.  Economy  of  scale  is 
absent  in  the  small  duplicate. 

Catalyze  this  Defense  IT  sub-market  by  exposing  use  cases,  MOP,  MOE,  test  cases, 
standards,  and  especially  budgets  associated  with  all  Defense  information  processing 
requirements.  The  approach  to  metrics,  contracting,  and  process  automation  described 
above  is  part  and  parcel.  Eikewise,  a  persistent  Defense  enterprise  PEA  PlugTest 
environment,  as  explained  above,  can  serve  as  a  channel  between  this  marketplace  and 
Defense  project  offices.  (Gunderson  C. ,  2014) 
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Persistent  PlugTest  Development,  T&E,  Certification, 

and  Procurement  Environment 

Pre  Negotiated  Low  Barrier  Procurement  Vehicles 
Continuously  Evolving  COTS  and  GOTS  Products 
Reference  Instance  of  Open  System  Product  Line  Architecture 
Compliance,  Functionality,  and  Mission  Performance  Test  Suite 
Open  Standard  Virtual  Security  Layer 
Networks 


Automated  Workflow,  Design,  and  Compliance  Tools 
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Figure  5:  Conceptual  model  for  using  the  COTS  IT  marketplace,  and  Defense  enterprise  PLA,  to 
hold  competition,  perform  AoA,  do  risk  mitigating  prototyping,  pre-certifying  useful  components, 
and  conveniently  procuring  lifecycle  supported  capahility  to  programs  across  the  Defense  acquisition 
portfolio. 
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